docker run -d --name mysql-a -p 23307:3306 \
-v $(pwd)/conf:/etc/mysql/conf.d \
-v $(pwd)/data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=root \
mysql
$ cat my.cnf
[mysqld]
server-id=1
log-bin=mysql-bin
$ CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
$ GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
$ FLUSH PRIVILEGES;
docker run -d --name mysql-b -p 23307:3306 \
-v $(pwd)/conf:/etc/mysql/conf.d \
-v $(pwd)/data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=root \
mysql
$ cat ../../mysqlb/conf/my.cnf
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
secure-file-priv= NULL
server_id=100
log-bin=mysql-slave-bin
relay_log=edu-mysql-relay-bin
$ docker inspect -f '{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' a4--这个是容器id
/mysql-b - 172.17.0.3
docker inspect -f '{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 52--这个是容器id
/mysql-a - 172.17.0.2
mysql -uslave -p123456 -h172.17.0.2 --get-server-public-key
,否则会报错error: Authentication requires secure connection.
,因为mysql8中caching_sha2_password 是默认的身份验证插件注意:master_log_file 和master_log_pos是在主库执行 show master status;命令后可以获取到
change master to master_host='172.17.0.2', master_user='slave', master_password='123456', master_port=3306, master_log_file='mysql-bin.000001', master_log_pos= 157, master_connect_retry=30;
stop slave;reset slave;
重置主库信息show processlist
来查看备库的同步binlog的线程,比如我这个,线程端口45976 state说已经全部同步到备库了,等待更多的更新。
有两种复制方式,一种是基于语句的复制(逻辑复制),这种方式在MySQL版本3的时候就存在了。另一种就是基于行的复制方式,这是在MySQL版本5提出来的。而具体支持哪种方式和
在这种模式下,binlog中记录的是那些造成数据更改的SQL,并在备库上重放这些SQL。这种模式的优点就是二进制日志里的事件更加紧凑,而且binlog的日志量会更小,比如我们更新了几十万条记录,而日志里面只记录了一条update语句。
但是缺点也是明显的,比如主库和备库的执行时间有可能会不一致,导致数据的时间戳也不一样。第二点就是这种记录日志必须是串行的执行,那么我们可能就需要更多的锁来保证它是串行的。
MySQL5.1以后开始支持行的复制,这种方式就是将实际数据存储到binlog里面,这种方式可以保证主备库的数据完全一致。而且不需要逻辑的binlog,复制数据的效率也更高。而且对于较为复杂的sql来说,这种方式也更高效,因为你中间不论执行了多少sql,我日志只记录物理日志,可能就是一行数据。但是对于一些update操作,那么每行被更改的数据都得记录到binlog里面。而且binlog的可读性比较差,我们不知道执行了哪些sql语句。
如果声明是mixed,MySQL则动态切换的,基于语句的复制执行不了的时候,就会采取行复制。我们也可以根据SHOW VARIABLES LIKE 'binlog_format'
来查看当前的复制方式。
相关参考添加链接描述 我们可以通过mysqlbinlog分析binlog,其中最常用到两个参数--base64-output和--verbose
base64-output AUTO: 默认为AUTO方式,原始的记录binlog events的方式。如果要通过binlog恢复数据(mysqlbinlog log_file | mysql -h server_name),必须使用AUTO方式 NEVER: 不显示binlog statements,遇到ROW格式的binlog直接报错 DECODE-ROWS: 压缩显示row格式events
verbose 将行模式下的binlog以注释的SQL语句的形式显示,在适用的情况下,还包括表的分区信息。即通过伪代码的方式重构出行数据改变的等价的SQL语句
查看binlog是否开启show variables like 'log_bin';
查看binlog的记录方式show variables like 'binlog_format%';
通过flush binary logs
命令关闭当前使用的binary log,然后打开一个新的binary log文件,文件的序号加1
执行一个insert操作
在不加任何参数的情况下,我们看到的日志是压缩过的
我们通过mysqlbinlog mysql-bin.000005 --base64-output=DECODE-ROWS -vv
查看日志(v就是verbose参数简写)
我们执行一个update语句看一下日志是什么样子
mysql> update user set name='www.acurd.com' where id>2;
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2 Changed: 2 Warnings: 0
我们发现被解析成了两个update语句
$ cat my.cnf
[mysqld]
server-id=1
log-bin=mysql-bin
default_authentication_plugin=mysql_native_password
binlog_format=statement
show variables like 'binlog_format%';
flush binary logs
update user set name='acurd' where id>1;
mysqlbinlog mysql-bin.000008
,日志中记录的就是我们执行的SQL